Existing Universal Mobile Telecommunications System (UMTS) platforms already integrate several radio access technologies such as the so-called General Packet Radio Service (GPRS), Enhanced Data rates for GSM Evolution (EDGE), Wideband Code Division Multiple Access (WCDMA), and Evolved HSPA (eHSPA) in one platform. Concerning packet switched services, a UMTS mobile is independently of the current radio access technology (RAT) always connected to the same domain for packet services, the GPRS core network packet domain. Thus the User Equipment (UE) always uses the same principles for Internet Protocol (IP) bearer/connection management and allocation between the UE and the network.
The IP bearer/connection management and allocation in the GPRS packet domain is based on Primary Packet Data Protocol (PDP) contexts and Secondary PDP contexts and comprises functions for activation, deactivation and modification of them, as being described in the specification document issued by the Generation Partnership Project, named 3GPP TS 24.008 “Mobile Radio Interface Layer 3 specification; Core Network Protocols; Stage 3”, which is herewith included by reference, thereby especially including the description of handling of Traffic Flow Templates (TFTs) and Quality of Service (QoS) profiles being specified per (Secondary) PDP contexts.
In existing mobile phone platforms, the IP bearer/connection management and allocation as specified by 3GPP for the GPRS packet domain is also the basis for the IP bearer/connection management and allocation functionality provided towards applications.
This functionality might be provided through any application programming interface (API). For internal applications, this functionality may be provided through the OPA (Open Platform API) interface, which is the name a mobile phone platform being developed by Telefonaktlebolaget L. M. Ericsson. Alternatively (e.g., for external applications) this functionality may be provided through the so-called AT command interface as described in the document: 3GPP TS 27.007 “AT command set for User Equipment (UE)”, hereby incorporated by reference. To simplify the description in the following exemplarily only the AT command interface is considered, which in addition is an interface that is not only used by Ericsson mobile phone platforms, but probably by all wireless 3GPP based modems as it is part of the 3GPP standard.
Instead of using (Primary) PDP Contexts and Secondary PDP Contexts as in the GPRS packet domain, the Evolved Packet System (EPS), which is the packed-switched domain used for the so-called Long Term Evolution (LTE) radio technology being specified by the above-mentioned 3GPP, defining Default Bearers, Dedicated Bearers and Service Data Flows (SDFs) in the so-called Non-Access-Stratum (NAS) protocol, e.g. being specified in the documents 3GPP TS 23.401 “GPRS Enhancements for E-UTRAN access” and 3GPP TS 24.301 “Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Core Network Protocols; Stage 3”. With regard to the SDFs, it should be mentioned that meanwhile the standard defined a further term, i.e. the Traffic Flow Aggregate, refer to TS 23.401, e.g. section 4.7.1 and the figure in section 4.7.2.2.
An SDF is always based on a Bearer. This also holds for a Traffic Flow Aggregate. Whenever statements regarding the term SDF are made in this document, such statements may also apply to the term Traffic Flow Aggregate. Several SDFs or Traffic Flow Aggregate with the same QoS may build an aggregated SDF or Traffic Flow Aggregate and may be mapped to the same Bearer. Contrary to the existing GPRS packet domain, where the decision of how to map SDFs (denoted as Traffic Flow Template in existing GPRS packet domains) and (secondary) PDP Contexts is done in the UE, in EPS the network decides how the mapping shall be done. This means an LTE Resource Allocation Request for an SDF or a Traffic Flow Aggregate issued by the application via NAS signaling can either return a new Dedicated Bearer with an SDF or a Traffic Flow Aggregate or return an already existing bearer with an additional SDF or Traffic Flow Aggregate. For the existing GPRS packet domain, the corresponding Secondary PDP Context Activate Request always returns a new (secondary) PDP Context. In both latter cases, a so-called outgoing packet switched (PS) connection is issued.
An incoming PS connection is characterized by the fact that from the UE perspective, no application has triggered the establishment of such a PS connection. The initiation is perceived as unsolicited. This type of PS connection is not supported by e.g. pre-release 7 3 GPP networks, or by other cellular network e.g. CDMA (Code Division Multiple Access).
In case of an outgoing PS connection, the application is the initiator, e.g. in LTE when the application issues a BEARER RESOURCE ALLOCATION REQUEST in network signaling (NS), the network responds with an activation (i.e. ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST) or modification (i.e. MODIFY EPS BEARER CONTEXT REQUEST) of an EPS bearer.
In case of an incoming PS connection the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST or MODIFY EPS BEARER CONTEXT REQUEST would be received by the UE without an explicit trigger by the application. In the latter case, the modification of an existing EPS bearer may be sent to establish a new service flow.
There are may be several possibilities to implement the handling of incoming PS connections. One conventional concept is described in the following.
A conventional implementation of the handling of an incoming PS connection is shown in FIG. 7.
FIG. 7 shows a user equipment 30 having an LTS NS stack 36, a connection manager 34 and an application 32. User equipment 30 may be communicatively coupled to network 40 thereby constituting a communication system 50.
The incoming PS connection is commissioned by the connection manager 34 as soon as the application 32 initiates the connection setup.
An ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST 42 is received by the LTE NS stack 36 of the UE 30. LTE NS stack 36 forwards a connection setup request 44 to the connection manager 34 which, in turn, may send an accept reply 46 to the LTS NS stack 36. Next, an ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT 48 is sent from the LTS NS stack 36 to the network 40.
Application 32 may send a connection setup request 50 to the connection manager 34 which, in turn, commissions the PS connection and may send back a response 52 to the application 32.
FIG. 8 illustrates as to how an outgoing PS connection is established.
Application 32 sends a connection setup request 60 to connection manager 34 which forwards the connection setup request 60 to LTE NS stack 36. LTE NS stack 36 then sends a BEARER RESOURCE ALLOCATION REQUEST 62 to the network 40 responding, in turn, to the LTE NS stack 36 with an ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST 64. Then, a connection setup response 66 is sent from the LTE NS stack 36 to the connection manager 34 which, in turn, sends a response 68 to the application 32 and an accept message 70 to the LTE NS stack 36. An ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT 72 is then sent from the LTE NS stack 36 to the network 40.
Hence, the instance which manages the outgoing PS connections, i.e. the connection manager 34, has to handle also the incoming PS connection.
As shown in FIG. 9, a problem with the conventional implementation depicted in FIG. 7 and FIG. 8 arises when two radio-platforms, e.g. the LTE platform (which supports also the incoming PS connections) is acting as modem 70 and is connected to an existing/legacy radio access platform 74, e.g. WCDMA (which only supports outgoing PS connections).
FIG. 9, compare reference numeral 80, highlights (only exemplarily) the interface interactions which are not supported by the legacy platform 74 and which would have to be implemented in addition to interact with the LTE modem 70.
Hence, and referring to FIG. 10, in a conventional system application 32 uses connection manager 34 to trigger PS data connections into network. Triggered by application 32 with the connection setup request 60, the connection manager 34 configures the network signaling (NS) stack 36 with parameters for the Bearer like QoS, TFT and protocol type. The NS stack 36 uses the NAS protocol to signal this connection setup request towards the network 40. If a Resource Allocation was requested (see message 82), the network 40 provides either a Dedicated EPS Bearer or modifies an existing EPS Bearer. This mechanism shown in FIG. 10 is suitable for handling so-called outgoing connections. Further messages in this context (ACTIVATE DEDICATED EPS BEARER EVENT 84, ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT 86, BEARER RESOURCE ALLOCATION RESPONSE 88, and CONNECTION STATUS INFORMATION message 90) are shown as well.
This concept works fine for e.g. existing/legacy WCDMA radio access platforms where only this type of connections had to be supported. However it is no longer sufficient for future systems as PS data connections can also be triggered by the network 40:                e.g. LTE requires setup of a Default EPS Bearer together with the attach procedure, but there might be no application which immediately requires this Default EPS Bearer.        e.g. as shown in FIG. 11, before handover (HO), the current network triggers the destination network to setup all bearers. After the bearers were established, the destination network signals these Bearers to the UE as incoming connections. Usually this procedure is completely handled within the NS stack 36 and upper layers in particular the connection manager 34 are not affected at all. But in systems where multiple RATs are handled within separate platforms (e.g. LTE data modem 70 attached to a WCDMA radio access platform hosting the application 74), the connection manager 34 responsible for the destination network's platform has not yet been configured for the connections which existed in the previous RAT. Thus the connection manager 34 receives incoming PS data connections but does not know to which application each Bearer has to be connected. The procedure is illustrated in FIG. 11 and is initiated by a handover command 94 received by the network 40.        A server application in the network might decide to setup a Bearer, e.g. signal an incoming VoIP call.        
The messages used in FIG. 10 and FIG. 11 are based on NAS signaling between NS stack 36 and Network 40. All other communications are for illustration only but not based on any specific protocol.